Cooperating Constraint Solvers

We propose a general scheme for the cooperation of different constraint solvers. On top of a uniform interface for constraint we stepwise develop reduction systems which describe the behaviour of an overall combined system. The modularity of our definitions of reduction relations at different levels allows the definition of cooperation strategies for the solvers according to the current requirements such that our overall system forms a general framework for cooperating solvers. 1 Constraint Systems and Constraint Solvers The combination of several constraint solving techniques enables to solve problems that none of the single solvers can handle alone (for examples see [2, 4, 5]). Thus, we developed an open and very flexible combination mechanism. A signature Σ = (S, F, R; ar) is defined by a set S of sorts, a set F of function symbols, a set R of predicate symbols, and an arity function ar : F ∪R → S. A Σ-structure D = ({Ds | s ∈ S}, {fD | f ∈ F}, {rD | r ∈ R}) consists of 1. an S-sorted family of nonempty carrier sets Ds, 2. a family of functions fD, and 3. a family of predicates rD, appropriate to F and R. X = ⋃ s∈S X s is a many sorted set of variables. A constraint system is a tuple ζ = 〈Σ,D〉, a constraint over Σ is a string of the form r t1 . . . tm where r ∈ Rs1×...×sm and ti ∈ T (F, X)i (, i.e. ti is a term over F of sort si with variables from X). The set of constraints over Σ is denoted by Cons(Σ). Let ∀ψ resp. ∃ψ denote the universal closure and the existential closure, respectively. ∃ Ỹ ψ denotes the existential closure of formula ψ except for the variables occurring in the sequence Ỹ of variables. Let D be a Σ-structure, and let Φ be a constraint conjunction over Σ. Let var(Φ) denote the set of variables of Φ. A solution of Φ in D is a valuation σ : V → s∈S Ds of a finite set V of variables, var(Φ) ⊆ V , such that (D, σ) 2 ∀Φ holds. Solving Φ means finding out whether there exists a solution for Φ or not. A constraint solver consists of a collection of operations which can be used to solve and to transform constraints of a constraint system. A solver works on a constraint store C ∈ CStore which, in the following, consists of a disjunction of constraint conjunctions. C has the property that it is satisfiable in the corresponding structure D, i.e. D 2 ∃C holds. 2 A Uniform Interface for Constraint Solvers To enable a cooperation of constraint solvers to solve a given problem, the solvers need to exchange information. We want to enable them to communicate in such a way that a very tight cooperation is possible. Let L be the set of indices of constraint systems, μ, ν ∈ L. Let to each constraint system a constraint solver be assigned. The following functions built our uniform interface for constraint solvers: 1. tell: Cons(Σν)× CStoreν−→ {truechanged, trueredundant, false} × CStoreν 2. proj: P(X)× CStoreν −→ CStoreν 3. projν→μ: P(X)× CStoreν −→ CStoreμ 1. The (partial) function tell is due to constraint satisfaction, i.e. an operation which is usually offered by constraint solvers. tell adds a constraint c ∈ Cons(Σν) to a constraint store C ∈ CStoreν if the conjunction of c and C is satisfiable, i.e. if D 2 ∃(C ∧ c) holds. We require tell to be defined as follows: if tell(c, C) = (trueredundant, C), then D 2 ∀(C −→ c), if tell(c, C) = (truechanged, C ′), where D 2 ∀((C ∧ c) ←→ C ′), then D 2 ∃(C ∧ c), if tell(c, C) = (false, C) then D 6 2 ∃(C ∧ c). 2. The function proj is due to the operation constraint projection of constraint solvers. Usually, the aim of projecting a constraint store C ∈ CStoreν wrt a sequence Ỹ (with Y ⊆ X) of variables which occur in C is to find a disjunction C ′ of conjunctions of constraints which is equivalent to ∃−Ỹ C and where the variables which do occur in C but not in Ỹ are eliminated: Dν 2 ∀(∃−Ỹ C ←→ C ′). However, since sometimes it is not possible to compute C ′ or it is not possible to compute it efficiently, we require proj to be defined as follows: proj(Y,C) = C ′, where Y ⊆ X and Dν 2 ∀(∃−Ỹ C −→ C ′). 3. Since we want to use projections for information exchange between the different constraint solvers, we need a function which projects a constraint store C wrt another constraint system ζμ, μ ∈ L\{ν}. projν→μ can be defined by means of proj and a conversion function. Thus each single constraint solver can be regarded as black box solver equipped with a projection function which allows the projection of the constraint store wrt a set of variables. These black box solvers are extended by functions for converting projections wrt other constraint systems. Example 1. Consider a solver CSrat for arithmetic constraints over rational numbers, and a solver CSFD of a finite domain constraint system ζFD. The projection functions proj and projFD→rat of CSFD could work as follows: proj(x,C) = x ∈FD {4, 5, 6}, and projFD→rat(x,CFD) = ((x ≥ 4) ∧ (x ≤ 6)), where C = ((y = 3) ∧ (x > y) ∧ (x ∈FD {2, 3, 4, 5, 6})). The function tell of CSrat could yield the following results: tell((x = 4), C) = (truechanged, C ′), where C = true and C ′ = (x = 4), tell((x > 3), C ′) = (trueredundant, C ′), and tell((x < 3), C ′) = (false, C ′). ¤ Clearly, the projection functions proj and projν→μ, ν, μ ∈ L, must be defined in such a way that, first, projecting a constraint store wrt another constraint constraint constraint meta constraint solver solver CS1 solver ... constraint stores CSk C1 Ck constraint pool Fig. 1. Architecture of the overall system system, no solutions of the constraints of the store are lost and, second, that a projection of a constraint store implies previous projections of this (at a previous time less restricted) store. We call these required properties soundness and monotonicity, a formal description is left out because of space limitations. We require the functions tell, proj, and projν→μ, ν, μ ∈ L, to be computable. 3 Combination of Constraint Solvers The Architecture. Figure 1 shows the architecture of our overall system for cooperating constraint solvers. To every individual solver CSν a constraint store C is assigned. The meta constraint solver coordinates the work of the different individual solvers. The meta solver manages the constraint pool. Initially, the constraint pool contains the constraints of the constraint conjunction Φ which we want to solve. The meta constraint solver takes constraints from the constraint pool and passes them to the constraint solvers of the corresponding constraint domains (step 1). Each of the individual constraint solvers is able to handle a subset of the set of constraints of the constraint pool independently of the other solvers, the individual solvers propagate the received constraints to their stores by tell (step 2). The meta constraint solver manages the exchange of information between the individual solvers. It forces them to extract information from their constraint stores by projν→μ. This information is added by the meta constraint solver to the constraint pool (step 3). The procedure of steps 1-3 is repeated until the pool contains either the constraint false or the constraint true only. If the constraint pool contains false only, then the initially given conjunction Φ of constraints is unsatisfiable. If the pool contains true only, then the system could not find a contradiction. Solutions of Φ can be retrieved from the current constraint stores. Using the described mechanisms, each individual solver deals with more information than only that of its associated constraints of Φ. Syntax. To allow to solve a conjunction of constraints, where every constraint may contain function symbols and predicate symbols of different constraint systems, it is necessary to detect overloaded symbols by analysis and to convert the constraint conjunction into a conjunction such that every constraint is defined by symbols of exactly one constraint system (by flattening as usually). Operational Semantics. We describe the operational semantics of our system by means of a reduction relation for overall configurations. An overall configuration H consists of a formal disjunction i∈{1,...,m}Gi of configurations Gi. Formal disjunction ∨̇ is commutative. A configuration G = P ̄ ν∈L C corresponds to the architecture of the overall system (Fig.1). It consists of the constraint pool P which is a set of constraints which we want to solve and the conjunction ∧ ν∈L C ν of constraint stores. We lift the application of the functions tell resp. projν→μ to the level of overall configurations and define the two basic relations prop resp. put proj which are the basis of the stepwise definition of the operational semantics. We define strategies for cooperating constraint solvers, i.e. reduction systems for overall configurations using these basic relations. In general, in one derivation step one or more configurations Gi, i ∈ {1, . . . , m}, are rewritten by a formal disjunction HGi of configurations: OConf1 = H1 ∨̇ G1 ∨̇ . . . ∨̇ Hi ∨̇ Gi ∨̇ . . . ∨̇ Hm ∨̇ Gm ∨̇ Hm+1 =⇒ OConf2 = H1 ∨̇ HG1 ∨̇ . . . ∨̇ Hi ∨̇ HGi ∨̇ . . . ∨̇ Hm ∨̇ HGm ∨̇ Hm+1 Thus, first, we define a derivation relation for configurations and, based on this, we define a derivation relation for overall configurations. Step 1. Definition of a derivation relation for configurations (production level). The simplest possibility to define a derivation step Gi → HGi is to chose (nondeterministically) exactly one constraint c ∈ Cons(Σν), ν ∈ L, from the constraint pool of Gi and to propagate it to its associated constraint store C building a new configuration G′ i (using the basic relation prop). This is followed by projections of the newly built constraint store C ′ν wrt other constraint systems building the new overall configuration HGi (using put proj). There are many other possibilities to define a strategy for the production level. We are able to let the solvers work in parallel as well as to fix the order of the constraint systems or constraints itself which are propagated next which enables to regard choice heuristics, for example to delay particular constraints, as for naive solving nonlinear constraints. Step 2. Defining a derivation relation for overall configurations (application level). A derivation step OConf1 =⇒ OConf2 for overall configurations is defined on the basis of the derivation relation for configurations (at production level). There are as well many possibilities: for example, we may define a derivation step such that the derivation of exactly one configuration or the derivation of several configurations in parallel or concurrently is allowed. Using this two-step frame different reduction systems which realize different derivation strategies for the derivation of an initial overall configuration to normal form can be described. An initial overall configuration is a configuration G0 = PΦ ̄ ∧ ν∈L C ν 0 , where the constraint pool PΦ contains the constraints of the conjunction Φ which we want to solve and all constraint stores C 0 , ν ∈ L, are empty, i.e. they contain the constraint true only. 4 Conclusion and Related Work We shortly presented a general scheme for cooperating constraint solvers. A uniform interface for the solvers allows to formally specify the information exchange between them. Because of this information exchange the overall combined system is able to solve constraint conjunctions which the single solvers are not able to handle. The modularity of our definitions of the basic relations and of the derivation relations at production level as well as at application level allows the definition of derivation strategies for cooperating solvers according to the current requirements, like properties of the particular constraint solvers as well as properties of the underlying software and hardware. Since our approach allows the integration of constraint solvers of very different constraint systems it is possible to integrate different host languages into the system by treating them as constraint solvers. In [1] we have shown the integration of a functional logic language. This new point of view on the host language of such a system and the possibility to define tight cooperation strategies according to the current requirements allow to specify a wide range of systems of cooperating solvers such that our overall system forms a general framework for cooperating solvers. Cooperating solvers have been investigated from different points of view [2– 6]. Usually this are very specialized approaches and their cooperation strategies are fixed. Our approach allows the definition of similar strategies and even a finer grained definition of strategies according to the current requirements. As far as for the mentioned approaches the form of constraints exchanged between the solvers is given, we are able to express this as well by means of our interface functions. For example, the main idea behind the combination approach in [6] is a mechanism which controls variable equality sharing which is an instance of information exchange by projections as done in our approach.